全球很多大厂都在用的Nitro PDF Pro 被曝7个 RCE 0day 漏洞（来看详情）

 聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士团队

Nitro PDF Pro 的当前版本13.2.3.26被曝至少存在一个 CVSS v3 评分为8.8的漏洞，可导致攻击者在受害者主机上远程执行代码。目前第三方正在推出修复方案。

开发者尚未发布关于该漏洞的官方补丁。攻击者可在易受攻击的软件版本中打开特殊构造的 PDF 文件利用该漏洞。

Nitro PDF 的客户多数是企业。企业客户遍布全球，使用它作为 Adobe Acrobat Pro 的替代品。其客户包括澳大利亚太平洋国家铁路货运运营商、德国汽车制造商 Continental、Zebra Technologies （资产跟踪解决方案）、T-Mobile Austria（电信）、Swiss Re（保险）以及 JLL（资产管理）。

将推出微补丁修复7个漏洞

上述提到的这个漏洞的编号是 CVE-2019-5050，它是思科 Talos 团队在 Nitro PDF Pro 12.12.1.522中发现并在本周早些时候披露的六个漏洞之一。该漏洞存在于软件的 PDF 解析功能中。

该漏洞至少可导致崩溃后果，但研究人员认为只需再稍微投入，攻击者就可能在当前用户上下文中在系统上执行任意代码。

0Patch 微补丁平台所属公司Acros Security 的首席执行官 Mitja Kolsek 发现该问题也存在于9月27日发布的 Nitro PDF Pro 当前版本 13.2.3.26 中。

微补丁是仅解决某软件产品中需要解决的某个漏洞的小部分代码。0Patch 是微补丁推送代理，无需重启系统即可应用，因为微补丁是在软件运营时应用到内存中的。

上周五，Kolsek 表示阻止滥用CVE-2019-5050漏洞的微补丁已可用，将在本周一通过一份 Pro 许可证的方式推送给客户。

虽然CVE-2019-5050是思科 Talos 研究人员已证实的影响 Nitro PDF Pro 最新版本的唯一一个安全问题，但 Kolsek 认为其它版本也受影响。如属实，则会为所有六个漏洞发布微补丁。

而这些漏洞并非 Nitro PDF 中暴露的唯一问题。两年前就有研究人员向 Acros Security 和 Nitro Software 报告过一个类似问题，但它从未被修复且也影响最新版本。

Mitja Kolsek 表示，“我们将其作为推出微补丁的演练，但并不想公开补丁，因为这个 0day 并未公开，因此我们实际上通过补丁的方式将其公开了。”

然而，随着这六个漏洞被公开，再公开一个也不会改变什么，因此0Patch 也将为这个0day 发布微补丁。

CVE-2019-5050 详情

思科 Talos 团队在博客中详细说明了该漏洞的情况，如下：

Nitro Pro 的 PDF 解析功能中存在一个潜在的远程代码执行漏洞。特殊构造的 PDF 文件可触发该漏洞，从而引发潜在的代码执行问题。

当解析 PDF 文档的页面树时，解析器混淆 (parser confusion) 可导致 /Page 对象被当做 /Pages 对象。通常，/Pages 对象包含 /Kids 对象数组，而后者本身可以是 /Pages 或 /Page 类型。页面对象应该定义页面的内容。在 NitroPDF 中，当 /Page 对象错误地包含 /Kids 数组和 /Count，而 /Count 值指定期望的 kid 对象数量时，该 /Page 对象将被解析为 /Pages 对象。此外，如果文档中的实际对象之间存在差异，即 /Kids 数组中的对象数量以及 /Count 的值之间存在差异，那么就会触发内存访问越界的后果。如下部分的 PDF 文档会引发崩溃：

2 0 obj
<< 
/Count 1
/Kids [  3 0 R ] 
>> 
endobj

3 0 obj
<< 
/Type /Page
/Count 20
/Kids [ 4 0 R ] 
>> 
endobj

对象 2 0 是一个正确的 /Pages 文档并指向其中一个 /Kids 对象 3 0。对象 3 0 声明自己具有 /Page 类型而非 /Pages，但它仍然包含 /Kids 和 /Count。在 NitroPDF 中对此解析会导致如下崩溃情况：

(3d18.6774): Access violation - code c0000005 (!!! second chance !!!)
npdf!PDDocUpdateTextCache+0x5400:
00007ff9`1dee6890 410f1001        movups  xmm0,xmmword ptr [r9] ds:000001be`3fc211c0=????????????????????????????????
0:000> k 5
 # Child-SP          RetAddr           Call Site
00 00000030`f49fe090 00007ff9`1ded52b4 npdf!PDDocUpdateTextCache+0x5400
01 00000030`f49fe0d0 00007ff9`1dedbfba npdf!PDWordFinderReleaseWordList+0x10d44
02 00000030`f49fe210 00007ff9`1deeadee npdf!PDDocAcquirePage+0x3a
03 00000030`f49fe260 00007ff9`1dee6de3 npdf!PDDocUpdateTextCache+0x995e
04 00000030`f49fe2a0 00007ff9`1dee0811 npdf!PDDocUpdateTextCache+0x5953

导致上述崩溃后果的原因在于对 r9 所指向的无效内存的读取访问权限所致。如果我们看下余下的崩溃基本块内容，可以看到：

.text:00000001803C6890 movups  xmm0, xmmword ptr [r9]
.text:00000001803C6894 add     r9, 18h
.text:00000001803C6898 add     rax, 18h
.text:00000001803C689C movups  xmmword ptr [rax-18h], xmm0
.text:00000001803C68A0 movsd   xmm1, qword ptr [r9-8]
.text:00000001803C68A6 movsd   qword ptr [rax-8], xmm1
.text:00000001803C68AB cmp     r9, rcx
.text:00000001803C68AE jnz     short loc_1803C6890

以上代码本质上是一个 for 循环，它将内容从 r9 指向的内存复制到 rax 指向的缓冲区。在每个循环中，地址都增加 0x18。因此，我们就看到了越界读取的后果，之后直接是写入。R9中的初始越界值实际上是该函数的第4个参数，而rax间接地来自第3个参数。如果我们返回到调用该函数的位置，就会从 r9 和 r8（分别是源和目标）寄存器中看到如下内容：

npdf!PDWordFinderReleaseWordList+0x10d3f:
00007ff9`1ded52af e87c150100      call    npdf!PDDocUpdateTextCache+0x53a0 (00007ff9`1dee6830)
0:000> ?r8
Evaluate expression: 1863222632440 = 000001b1`d0b91ff8
0:000> ?r9
Evaluate expression: 1863222632896 = 000001b1`d0b921c0
0:000> dd r9
000001b1`d0b921c0  ???????? ???????? ???????? ????????
000001b1`d0b921d0  ???????? ???????? ???????? ????????
000001b1`d0b921e0  ???????? ???????? ???????? ????????
000001b1`d0b921f0  ???????? ???????? ???????? ????????
000001b1`d0b92200  ???????? ???????? ???????? ????????
000001b1`d0b92210  ???????? ???????? ???????? ????????
000001b1`d0b92220  ???????? ???????? ???????? ????????
000001b1`d0b92230  ???????? ???????? ???????? ????????

因此，当首次调用该函数时，寄存器 r9 已经将越界指向无效内存。该函数调用之前的代码实际上计算了偏移量，而该偏移量导致堆访问越界：

00007ff9`1ded5286 488b4628        mov     rax,qword ptr [rsi+28h]
00007ff9`1ded528a 8bcb            mov     ecx,ebx
00007ff9`1ded528c 48ffc1          inc     rcx
00007ff9`1ded528f 488d1449        lea     rdx,[rcx+rcx*2]                   [1]
00007ff9`1ded5293 4c8d0cd0        lea     r9,[rax+rdx*8]                    [2]
00007ff9`1ded5297 8b5c2440        mov     ebx,dword ptr [rsp+40h]
00007ff9`1ded529b 488d0c5b        lea     rcx,[rbx+rbx*2]                   [3]
00007ff9`1ded529f 4c8d04c8        lea     r8,[rax+rcx*8]                    [4]
00007ff9`1ded52a3 488d942488000000 lea     rdx,[rsp+88h]
00007ff9`1ded52ab 488d4e28        lea     rcx,[rsi+28h]
00007ff9`1ded52af e87c150100      call    npdf!PDDocUpdateTextCache+0x53a0 (00007ff9`1dee6830)

如上 [1]中，数组的索引被计算为 rdx。rcx 中的值直接来自对象中的 /Count 值。然后在[2]中，计算了内存数组的偏移量，而 r9 指向其最终值。同样，在 [3] 和 [4] 中，计算了目标指针，只有 ebx 中的值实际上表示了目前为止找到的有效的 /Page 对象的数量。

应该注意的是，这种解析器混淆可发生在页面树的任何数量的级别上，对内存布局和指针算法产生影响。通过操纵该布局、有效的 /Page 和PDF 文档中的其它对象，该漏洞可导致任意内存访问越界的后果。通过仔细控制溢出块附近的内存内容，该溢出可能被滥用于覆盖相邻的堆内存，最终导致任意代码执行后果。

安全报告被垃圾邮件淹没？

思科 Talos 团队最开始在5月7日向 Nitro Software 发送漏洞报告，但后者在8月7日也就是三个月之后才予以回复，而这是在研究人员第三次跟进之后才回复的。

Nitro Software 表示，之前的漏洞报告被垃圾邮件文件夹所淹没。而两年前发送的那份报告也可能遭到了同样的命运，尽管这种行为对于向全球大规模企业提供解决方案的供应商而言也是一种非常严重的失误。

思科的漏洞披露策略规定，供应商修复漏洞的时限是90天。如超过规定而供应商未能缓解这些风险或者未对报告做出回应，则公开漏洞报告。

思科 Talos 团队决定延期 Nitro Software 漏洞披露事件。Nitro Software 表示，“将在未来版本中修复这些问题”，但并未给出时间线。

Nitro PDF Pro 发布官方补丁之时将是其在近两年中发布的最新安全更新公告。该公司发布修复方案的最近时间是2017年11月17日，发布的是软件分支11.x和10.x的补丁。

推荐阅读

原文链接

https://www.bleepingcomputer.com/news/security/nitro-pdf-pro-to-get-micropatches-for-7-potential-rce-bugs/

https://talosintelligence.com/vulnerability_reports/TALOS-2019-0819

题图：Pixabay License

本文由奇安信代码卫士编译，不代表奇安信观点，转载请注明“转自奇安信代码卫士 www.codesafe.cn”

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。